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(57) Abstract 

A computer implemented system en- 
ables a global user interface. The system 
includes a plurality of application engines 
(110, 114) and a user interface process 
(124). The system also includes a visual 
infomiation broker (118) that has dynam- 
ically loadable adapters (120, 122) where 
each adapter (120, 122) is appropriate for 
accessing one of a plurality of types of en- 
gines. The visual information broker (118) 
can thereby interface between an engine in- 
terface (112, 1 16) of an application engine 
(110, 114) and the user interface process 
(124) by dynamically loading an adapter 
(120, 122) appropriate for that type of en- 
gine. The computer system also can en- 
able a global messaging bus. The system 
includes native messaging supported by a 
network messaging layer (180). A plu- 
rality of message bus manager processes 
(176) each include a dynamically loadable 
message bus adapter (178) and a message 
bus application program interface (174). 
The message bus manager processes (176) 
thereby enable global messaging between 
software applications (172) by adapting to 
the native message protocol of the network 
messaging layer (180). 
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UNIVERSAL ADAPTER FRAMEWORK AND PROVIDING 
A GLOBAL USER INTERFACE AND GLOBAL MESSAGING BUS 



TECHNICAL FIELD OF THE INVENTION 

This invention relates in general to the field of 
supply chain, enterprise and site planning, and more 
particularly to a system and process having a universal 
adapter framework and providing a global user interface 
and a global messaging bus. 

BACKGROUND OF THE INVENTION 

Supply chain, enterprise and site planning 
applications and environments are widely used by 
manufacturing entities for decision support and to help 
manage operations. Decision support environments for 
supply chain, enterprise, and site planning have evolved 
from single-domain, monolithic environments to multi- 
domain, monolithic environments. Conventional planning 
software applications are available in a wide range of 
products offered by various companies. These decision 

■ 

support tools allow entities to more efficiently manage 
complex manufacturing operations. However, supply chains 
are generally characterized by multiple, distributed and 
heterogenous planning environments. Thus, there are 
limits to the effectiveness of conventional environments 
when applied to the problem of supply chain planning due 
to monolithic application architectures. Further, these 
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problems are exacerbated when there is no one "owner" of 
the entire supply chain. 

It is desirable for the next evolutionary step for 
planning environments to establish a multi-domain, 
5 heterogenous architecture that supports products spanning 
multiple domains, as well as spanning multiple engines 
and products. The integration of the various planning 
environments into a seamless solution can enable inter- 
domain and inter-enterprise supply chain planning. 

IQ Further, an important function provided by some planning 
applications is the optimization of the subject 
environment rather than simply tracking transactions. In 
particular, the RHYTHM family of products available from 
12 TECHNOLOGIES provide optimization functionality. 

15 However, with respect to planning at the enterprise or 

supply chain level, many conventional applications, such 
as those available from SAP, use enterprise resource 
planning (ERP) engines and do not provide optimization. 
It is thus also desirable to expand planning analysis and 

20 optimization to the inter-enterprise or inter-domain 

level to enable planning optimization across the supply 
chain. 

SUMMARY OF THE INVENTION 

25 In accordance with the present invention, a system 

and process having a universal adapter framework and 
providing a global user interface and a global messaging 
bus are disclosed that provide advantages over 
conventional supply chain, enterprise and site planning 

30 environments. 

According to one aspect of the present invention, a 
computer implemented system enables a global user 
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interface. The system includes a plurality of 
application engines each having an engine interface and 
composed of a plurality of types of engines. The system 
also includes a user interface process providing an 
5 interface based upon user interface components. The 
system further includes a visual information broker 
operating as a middle tier to the plurality of 
application engines and the user interface process. The 
visual information broker has dynamically loadable 

10 adapters where each adapter is appropriate for accessing 
one of the plurality of types of engines. The visual 
information broker can thereby interface between the 
engine interface of an application engine and the user 
interface process by dynamically loading an adapter 

15 appropriate for that type of engine. 

According to another aspect of the present 
invention/ a computer implemented system enables a global 
messaging bus. The system includes native messaging 
supported by a native message protocol across a network 

20 messaging layer. The system also includes a plurality of 
message bus manager processes where each message bus 
manager process is associated with a software 
application. Each message bus manager process includes a 
dynamically loadable message bus adapter appropriate for 

25 the native message protocol and communicating across the 
network messaging layer and includes a message bus 
application program interface appropriate for and 
communicating with the associated software application. 
The plurality of message bus manager processes enable 

30 global messaging between the software applications by 
adapting to the native message protocol of the network 
messaging layer. 
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A technical advantage of the present invention is 
that the visual information broker provides a common 
interface which can be accessed by the user interface 
regardless of the type of engine from which information 
5 is obtained. The visual information broker can also 

load-balance application engines of the same type. The 
application engines supported can include a wide variety 
of data models, including tables, trees, name-value 
pairs, multi-dimensional, and object graphs. Another 

10 technical advantage is that, in order to add support of a 

new engine or data model, only a new adapter needs to be 
added to the visual information broker. 

A further technical advantage of the present 
invention is that the visual information broker and 

15 adapters allow user interface-oriented data models from 
multiple engine types to be adapted into a common data 
model oriented for the global user interface. 

Additional technical advantages should be readily 
apparent to one skilled in the art from the following 

20 figures, descriptions, and claims. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

A more complete understanding of the present 
invention and advantages thereof may be acquired by 
referring to the following description taken in 
5 conjunction with the accompanying drawings, in which like 
reference numbers indicate like features, and wherein: 

FIGURE 1 is a block diagram providing an overview of 
one embodiment of a core environment that enables supply 
chain analysis and optimization according to the present 
10 invention; 

FIGURES 2A and 2B are block diagrams illustrating 
conventional many-to-many conversion for inter-domain 
analysis and one-to-many conversion for inter-domain 
analysis according to the present invention; 
15 FIGURE 3 is a block diagram of one embodiment of 

relationships among adaptation dimensions associated with 
inter-domain analysis and optimization according to the 
present invention; 

FIGURE 4 is a block diagram of the visual 
20 information broker (VIE) operating as a middle tier to 
various engines and other data sources according to the 
present invention; 

FIGURE 5 is a block diagram showing the VIE 
interaction with various data sources as well as browser 
25 and non-browser user interfaces according to the present 
invention; 

FIGURE 6 is a block diagram of a business object 
server operating as data server according to the present 
invention; 

30 FIGURE 7 is a block diagram showing different 

components of queuing and the global messaging bus 
according to the present invention; 
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FIGURE 8 is a block diagram showing transactional 
messaging between applications according to the present 
invention; 

FIGURES 9A and 9B are block diagrams of a naive 
5 approach to inter-domain analysis and optimization and of 
the use of model agents as partial replicas according to 
the present invention; 

FIGURES lOA and lOB are block diagrams of many-to- 
many interaction between domains and of simplified domain 
10 interaction enabled by the inter-domain connectivity 
plane according to the present invention; 

FIGURE 11 is a block diagram of one embodiment of an 
inter-domain connectivity plane according to the present 
invention; and 

15 FIGURE 12 is a block diagram of a hub and spoke 

collaboration network formed by engines on the inter- 
domain connectivity plane. 



DETAILED DESCRIPTION OF THE INVENTION 

20 FIGURE 1 is a block diagram providing an overview of 

one embodiment of a core environment/ indicated generally 
at 10, that enables supply chain analysis and 
optimization according to the present invention. Core 
environment 10 provides a framework for inter-domain and 

25 inter-enterprise analysis and optimization. This 

framework allows optimization in the extended enterprise 
distributed environment. The framework also provides an 
inter-domain decision support environment that allows 
optimization for the extended enterprise. The framework 

30 further allows the embedding of other applications within 
it and can be embedded within other applications. Core 
environment 10 integrates multiple engines along multiple 
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dimensions including user interface {VI ) , messaging, data 
access, data modeling and other dimensions. Core 
environment 10 provides scaleability, common protocols 
and security for supply chain planning and provides a 
5 universal adapter framework to provide connectivity 

between components and with other applications. All of 
the components and functionality within core environment 
10, which are discussed herein, generally can be 
implemented by software executing on a computer device 
10 comprising typical components such as a processor, 
memory, input/output (I/O) devices and data storage 
devices . 

As shown, core environment 10 includes a number of 
data sources 12 associated with planning environments 

15 that can be used by various enterprises and sites. Data 
sources 12 include, but are not limited to, legacy data 
sources (e.g., IBM mainframe and mid-range systems), 
relational database management systems (RDBMS) (e.g., 
ORACLE, SYBASE), enterprise resource planning systems 

20 (ERP) (e.g., SAP), 12 TECHNOLOGIES data sources, data 

warehouses and on-line analytical processing (OLAP) 
sources. Core environment 10 includes a supply chain 
data link 14 that provides a layer to interface to data 
sources 12. Supply chain data link 14 can, for example, 

25 be a layer established by the RHYTHM-LINK product 
available from 12 TECHNOLOGIES. 

Business object servers (BOS's) 16 work through 
supply chain link 14 to interface with associated data 
sources 12. Alternatively, BOS's 16 can interface 

30 directly to data sources 12. For each data source 12, 
BOS's 16 use a dynamically loaded adapter to interface 
with the particular data source 12 and use a common BOS 
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interface to communicate to higher levels within core 
environment 10. The structure and operation of BOS's 16 
are also shown and described below. As shown in FIGURE 
1, BOS's 16 can interface to planning engines 18 which 
5 comprise various domain engines that handle planning 
analysis and optimization across the supply chain. 

Planning engines 18 are integrated on an inter- 
domain connectivity plane 20. Inter-domain connectivity 
plane 20 provides an abstract layer for messaging and 

10 transfer of model agents that allow engines 18 to operate 
at the supply chain level. Inter-domain connectivity 
plane 20 is specifically geared towards inter-domain 
decision support, and the structure and operation of 
inter-domain connectivity plane 20 and its components are 

15 also described below. Among the functions provided by 

inter-domain connectivity plane 20 are messaging between 
domains, an advanced early warning system between domains 
for emergency events, the transfer of model agents and 
the enablement of loosely coupled optimization. Inter- 

20 domain connectivity plane 20 also allows interaction with 
custom applications 22 and support applications 24. 

A visual information broker (VIB) 26 interfaces to 
inter-domain connectivity plane 20 to obtain information 
from various sources and package that information into a 

25 common format. The common format allows global user 

interface (UI) 28 to use a library of interface 
components that does not need to be changed every time 
the information source changes. In one embodiment, user 
interface components are implemented using JAVABEANS or 

30 ACTIVEX user interface components, and the JAVA language 
is used to provide extensibility. Analogous to BOS's 16, 
visual information broker 26 uses dynamically loaded 
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adapters specifically designed to interface to particular 
sources of information. Core environment 10 also 
includes a global message bus and abstract queuing 30 
which enables interaction between engines 18 on inter- 
5 domain connectivity plane 20. In one implementation, 

synchronous communications are handled by common object 
request broker architecture (CORBA) and distributed 
component object model (DCOM) , and asynchronous 
communications are handled by supporting many messaging 

10 layers, including, but not limited to, TIBCO, MQSERIES, 

ACTIVEWEB and SMTP (simple mail transfer protocol) . 

Within core environment 10, global user interface 28 
supports a common user interface across multiple engines 
18 and sources 12. Global user interface 28 allows a 

15 common set of reusable, data-aware components to be 

established across the multiple engine types. A number 
of data-aware user interface components can be supported 
such as: tree, tree-table, table, two-dimensional and 
three-dimensional charts (line, bar, Gantt, pie) , maps 

20 and graphs, multi-dimensional, and axis-cross. Global 
user interface 28 also can establish a common 
extensibility mechanism, a common security framework and 
a common user model. 

Core environment 10 can support a number of distinct 

25 kinds of user interfaces, including, for example, an 

ACTIVEX user interface, a JAVABEANS -based stand alone 
user interface, a JAVABEANS -based browser user interface 
and a dynamic-SHTML servelet user interface. The ACTIVEX 
user interface can be supported via a COM interface to a 

30 data manager, which can be a sub-component of visual 

information broker (VIB) 26. Also, data aware ACTIVEX 
components that are aware of VIB 26 data models can be 
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provided. This user interface would also support 
JAVABEANS components wrappered as ACTIVEX. The 
JAVABEANS-based stand alone user interface can include 
JAVABEANS that are aware of VIE 26 data models. This 
5 user interface would support ACTIVEX components wrappered 
as JAVA components using the MICROSOFT JAVA virtual 
machine. The JAVABEANS-based browser user interface can 
be a pure JAVA user interface. It can be designed to run 
in any browser as well as on network computers. As a 

1.0 pure JAVA interface/ the user interface will run inside 
any JAVA virtual machine (JVM) . The dynamic-SHTML 
servelet user interface can be designed for low-bandwidth 
situations such as those found on the Internet. This 
approach distributes the processing at the server side 

15 producing dynamic HTML pages that are displayed on a web 
browser. 

In general/ core environment 10 is designed to 
integrate existing and future planning engines at 
multiple levels and possesses a number of key attributes. 

20 Core environment 10 is designed to be open and establish 
protocols by which applications can be developed to 
operate under core environment 10. Core environment 10 
is component based and uses standard component 
architectures. For example/ CORBA and DOOM can be used 

25 as a distributed component architecture/ and JAVABEANS 
and ACTIVEX can be used as user interface component 
architecture- By having a component architecture, core 
environment 10 allows changes to be released in pieces 
and not all at once, allows users to select and use only 

30 components that are useful, allows components to be re- 
used/ and allows third party components to be 
incorporated. 
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Core environment 10 can be scaleable in a variety of 
different ways. Components can be load balanced and 
multi-threaded which leads to higher throughput. As 
described below, the universal adaptor framework avoids 
5 the many-to-many issue which leads to greater 

scaleability . Further, security is handled by core 
environment 10 so that individual engines do not have to 
be worried about security. This also leads to greater 
scaleability. 

10 With respect to security, core environment 10 can 

provide a number of forms of security. For example, 
there can be security between user interface 28 and 
visual information broker 26 and messaging security. In 
both cases, both encryption as well as user 

15 authentication can be provided. An important aspect is 

that core environment 10 can implement security in such a 
way that it does not require each and every engine to be 
concerned with security. 

Core environment 10 may, however, place some minimal 

20 requirements on the engine architecture. In one 

implementation, core environment 10 makes the assumption 
that an interface can be provided to the engine that is 
either an external interface or an in-memory JAVA 
interface. In this implementation, if an external 

25 interface is provided, the interface can be a CORBA 

interface, a COM/DCOM interface, a shared library, 
structured query language (SQL), an object database 
interface or a socket interface. If an in-memory JAVA 
interface is provided, the interface can typically be 

30 accomplished by embedding a JAVA virtual machine (JVM) in 
the engine and writing a local JAVA interface (LJI) that 
calls the local native interface (LNI) via the JAVA 
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native interface (JNI) . Another assumption that can be 
made about the engines is that the engines have an 
ability to be a CORBA client and have the ability to 
marshall CORBA structures. Native components can be 
5 provided for both of these tasks. However, in this case, 
core environment 10 specifically does not make the 
requirement that an engine must be a CORBA server (which 
would require hooking up the engine's event loop with the 
CORBA event loop) . 

10 

Universal Adapter Framework 

One problem in creating core environment 10 is 
matching an interface (along some dimension) of one 
product or application with that of another. One 

15 possible solution is to write converters between all 

possible combinations of interfaces. However this leads 
to a classic many-to-many problem where the number of 
converters is unmanageable. FIGURE 2A is a block diagram 
illustrating this conventional many-to-many conversion 

20 problem for inter-domain analysis. As shown, an 

environment 40 may contain a plurality of products, 
applications, data sources or other entities 42 that need 
to interface with one another. In environment 40, there 
is a converter, represented by the lines, associated with 

25 the interface between each pair of entities 42. As can 
be seen, this many-to-many solution will generate a 
requirement to create and manage a prohibitively large 
number of converters as the number of entities 42 
increase. 

30 FIGURE 2B is a block diagram illustrating one-to- 

many conversion for inter-domain analysis according to 
the present invention. This solution is enabled by a 
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universal adaptor framework in which the different 
adaptation dimensions use the same mechanism for 
adaptation. As shown, an environment 44 can contain a 
plurality of products, applications, data sources or 
5 other entities 46. However, unlike environment 40 of 
FIGURE 2A, environment 44 further includes a universal 
interface 50. With this scheme, only one adapter 48 
needs to be created and managed between each entity 4 6 
and universal interface 50. In general, an adaptor 48 

10 maps a proprietary interface from an entity 4 6 into 
universal interface 50. This allows a one-to-many 
conversion instead of the many-to-many conversion of 
FIGURE 2A, Further, adapters 48 can be dynamically 
loadable such that an appropriate adapter 48 can be 

15 loaded when an interface to a particular entity 4 6 is 
needed and then removed if no longer needed. 

This universal adaptor framework works across 
multiple dimensions using dynamically loaded adaptors 48. 
These adaptation dimensions can include visual (handled 

20 by VIB) , data (handled by BOS's), messaging and queuing. 

Dynamically loaded adapters 48 help to establish openness 
within core environment 10 and can use the same mechanism 
across all adaptation dimensions. This reduces the 
learning curve for users and developers within core 

25 environment 10. 

Adaptation Dimensions 

FIGURE 3 is a block diagram of one embodiment of 
relationships among adaptation dimensions associated with 
30 inter-domain analysis and optimization according to the 
present invention. FIGURE 3 shows an example 
environment, indicated generally at 60, that includes 
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four adaptation dimensions — user interface, data, 
queuing and message bus — all of which involve 
dynamically loaded adapters. 

Beginning with data sources, environment 60 includes 
5 a planning engine 62 and data storage 64 accessed by a 
business object server (BOS) 66 using dynamically 
loadable adapters 68 and 70. An SAP based system 72 and 
an ORACLE based system 74 are linked through a RHYTHM- 
LINK application 76. A second BOS 78 then accesses both 

10 data storage 64 and RHYTHM-LINK application 76 using 

adapters 80 and 82. Similarly, a common data model 
storage 84 is accessed by a BOS 86 and a BOS 90 using 
adapters 88. BOS's 66, 78, 86 and 90 all interface to a 
domain engine 92, which can be one of a number of domain 

15 engines operating within a supply chain. In addition, 

RHYTHM-LINK application 76 can be enabled to interface 
directly to domain engine 92, and in particular can do so 
when domain engine 92 is an 12 TECHNOLOGIES' product. 
Domain engine 92, in turn, provides information to a 

20 visual information broker 94 through dynamically loadable 
adapters 96. Visual information broker then provides 
data to a common user interface (UI) 98 for providing a 
display to a user. Environment 60 also includes a global 
message bus 100 which uses adapters 102 to interface to 

25 native messaging functionality and allow engine 92 to 

interact with other domain engines. Global message bus 
100 also interfaces with a queue adapter 104 that uses 
adapters 106 to allow messages to be persisted on either 
a relational database management system (RDBMS) 108 or an 

30 object oriented database management system (ODBMS) 108. 
This persistence can form the basis for guaranteed 
message delivery. 
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The user interface adaptation dimension concerns the 
presentation of information to users and involves common 
user interface 98, visual information broker 94 and 
adapters 96, For example, if an engine 92 needs to be 
5 accessible from common user interface 98, then the engine 
92 should have visual information broker (VIB) adaptors 
96 created for it. Likewise, although not shown, if an 
application needs to embed an engine 92 into the 
application's user interface, then the application's user 

10 interface can make a call to visual information broker 94 

which, in turn, interfaces to engine 92. 

The data adaptation dimension concerns the 
accessibility of data to an engine 29 and involves BOS's 
66, 78, 86 and 90 and BOS adapters 68, 70, 80, 82 and 88. 

15 If an application or data source needs to be accessible 
from engine 92, then there should be business object 
server (BOS) adaptor created for the application or data 
source. 

The queue adaptation dimension concerns queues for 
20 transactions and is not directly illustrated in FIGURE 3. 
Queue adaptors, for example, allow queues to be built on 
transactional databases, including relational database 
management systems (RDBMS's), such as ORACLE and SYBASE, 
and object data base management systems (ODBMS's). Queue 
25 adapters can be built to any transactional database a 
main application or engine is using. The queue 
adaptation layer is also shown and described below. 

The message bus adaptation layer concerns 
communication over message layers and involves global 
30 message bus 100 and adapters 102. For example, if an 

application needs to have communication to an engine 92 
implemented over the application's native message layer. 
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then an adaptor 102 can be created to that native message 
layer. 

Visual Information Broker 
5 FIGURE 4 is a block diagram of the visual 

information broker (VIB) operating as a middle tier to 
various engines and other data sources according to the 
present invention. As shown, a first engine 110 (of type 
2) has an engine interface 112, and a second engine 114 

10 (of type 1) has an engine interface 116. The visual 

information broker (VIB) 118 accesses engine interface 
112 using an adapter 120 and accesses engine interface 
116 using an adapter 122. Visual information broker 118 
can then provide information to a user interface 124 

15 which can include a local caching proxy server 126. 

VIB 118 then has a common interface which can be 
accessed by user interface 124 regardless of the type of 
engine from which VIB 118 obtains information. As 
mentioned above, user interface 124 can thus include a 

20 library of data-aware components such as ACTIVEX and 
JAVABEANS components. VIB 118 can route incoming 
requests from user interface 124 to engines 110 and 114 
which are of different types. VIB 118 can also load- 
balance engines of the same type. Such a data manager 

25 sub-component of VIB 118 is a part of the universal 

adaptor framework described above. VIB 118 and adapters 
120 and 122 allow user interface-oriented data models 
from multiple engines 110 and 114 to be adapted into a 
common data model oriented for user interface 124. This 

30 forms a basis for common user interface 124. 

VIB 118 can provide an interface across multiple 
sources including databases, in-memory engines, CORBA 
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servers/ flat-files, messaging^ object databases, etc. 
VIB 118 uses dynamically loadable adapters as appropriate 
to interface with the sources. The adapters can be 
specifically designed to connect to desired source and to 
5 VIB 118. This scheme allows support of a wide variety of 
data models, including tables, trees, name- value pairs, 
multi -dimensional, and object graphs. 

FIGURE 5 is a block diagram showing interaction 
between the visual information broker and various data 

10 sources as well as browser and non-browser user 

interfaces according to the present invention. As shown, 
the environment can include a browser user interface 130 
and a non-browser user interface 132. Browser user 
interface 130 connects through a workstation 134 that 

15 provides a firewall 136 and an HOP tunnel 138. 

A visual information broker (VIB) 140 can provide 
access to information sources 142 (DCOM, CORBA) for both 
HOP tunnel 138 and non-browser user interface 132. VIB 
140 can also interface with a VIB 144. Another VIB 146 

20 can provide access to information sources 148 (SQL, OLAP, 

I2-FP, I2-SCP) for non-browser user interface 132. As 
with VIB 140, VIB 145 can also interface with VIB 144. 
VIB's 140, 144 and 146 can be designed to access multiple 
data sources simultaneously, and the data sources can 

25 include: CORBA servers, DCOM servers, COM objects, RDBMS 

data, ODBMS objects and in-memory objects. Further, 
VIB's 140, 144 and 146 can be load-balanced to divide the 
load across multiple servers or other sources of 
information, and this load-balancing can be transparent 

30 to user interface 130 or 132. 

Visual information brokers can support a multi- 
threaded environment with a thread-pool model where 
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individual requests can be executed in their own thread 
until a certain maximum number after which they can be 
queued. Visual information brokers also can be directly 
embedded in an engine and can run on the same machine as 
5 the engine for high-throughput compared to network 
access. 

In one embodiment, visual information brokers 
include data manager, event channel and page manager sub- 
components . The data manager sub-component can be 

10 accessible via CORBA as well as COM and supports multiple 
data models including: tree-table, name-value list, axis- 
cross, multi-dimensional and object graph. The data 
manager can also support client-originated execution of 
model agents. The event channel sub-component allows the 

15 common user interface to subscribe to and be notified of 
server events. The page manager sub-component can allow 
a user interface to be created in an SHTML format. This 
format allows inter-leaving of static HTML with dynamic 
servelets. It is more efficient than CGI since it does 

20 not require a separate process spawned per request, but 

only a separate thread per request (up to a maximum since 
it uses a thread-pool model) . The page manager also can 
be compatible with the JAVASOFT servelet application 
program interface (API) . It can load in standard 

25 servelet components as well as application-specific 

servelets. The page manager can be similar to a JAVASOFT 
JAVASERVER with a number of additional features and 
differences. The page manager can be instantiated stand- 
alone or within another process. In process 

30 instantiation allows a very tight coupling between the 

servelet and the process. The page manager can be load- 
balanced and is designed to work with a web server and 
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not be a replacement for one. The page manager also 
links servelet parameterization with page 
parameterization so that dynamic servelets can form 
direct parameterized links to SHTML pages. 

5 

Business Object Servers 

FIGURE 6 is a block diagram of a business object 
server (BOS) operating as a data server according to the 
present invention. A number of data sources 150 have 

10 associated dynamically loadable BOS adapter's 152 that 

interface between data sources 150 and a business object 
server (BOS) 154. Business object server 154 includes a 
BOS interface 156 which can be standard across business 
object servers. A BOS client 158 can then interface with 

15 business object server 154 through BOS interface 156. As 
shown, BOS client 158 can read from and write to data 
sources 150 through business object server 154, and 
business object server 154 can handle the specific 
interface with data source 150 via an appropriate BOS 

20 adapter 152. The dynamically loadable nature of BOS 

adapters 152 mean that they can be loaded as needed and 
then removed without having to otherwise affect the 
operation of business object server 154. 

In general, BOS client 158 can be a planning engine, 

25 and business object server 154 can serve up objects to 

the engine from multiple different data sources 150. In 
this manner, business object servers 154 form an integral 
part of the described universal adaptor framework. BOS 
adapters 152 adapt data from the multiple data sources 

30 150 into specific business objects. Each business object 
server can thus be classified by the data source 
interfaces to which it adapts. 
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BOS adapters 152 to data sources 150 can have a 
common model and an other model format. For the common 
model format, a standard BOS interface 156 and standard 
BOS adaptors 152 can be fused into a single object. 
5 Effectively, in this case, BOS adaptors 152 then provide 
only an object-relational mapping. For non-standard BOS 
adapters 152, an application can be provided to allow 
development of special business object servers 154 as 
well as BOS adaptors 152. For the other model format, 

10 there can be BOS adaptors 152 to many non-standard data 

sources 150, including enterprise resource planning (ERP) 
systems and other planning systems. BOS adaptors 152 can 
operate to make accessible proprietary non-standard data 
sources 150. For the other model format, an application 

15 can, again, be provided to allow development of special 
business object servers 154 and BOS adaptors 152. 

Queuing and Messaging 

FIGURE 7 is a block diagram showing different 

20 components of queuing and the global messaging bus 

according to the present invention. The queuing and 
global messaging are also built upon the described 
universal adaptor framework. With respect to queuing, a 
storage 160 can contain queues 162 that include 

25 transactions for a relational or object database 

management system (RDBMS, ODBMS) . A dynamically loadable 
queue adapter 164 provides an interface from a queue 
manager 166 to queues 162. Queue manager 166 includes a 
queue application program interface (API) 168 that can be 

30 standard across queue managers 166. A transactional 
message manager (TMM) 170 and an application 172 can 
interface to queue manager 166 via queue API 168. 
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Similarly, with respect to global messaging, 
transactional message manager (TMM) 170 and application 
172 can interface through a message bus API 174 to a 
message bus manager 176. Message bus manager 176, in 
5 turn, can use a dynamically loadable message bus adapter 
178 to interface to native messaging 180 of the 
underlaying native applications. This allows global 
messaging to be built on top of any third party messaging 
solutions including, for example, ACTIVEWEB, TIBCO, 

10 MQSERIES, NEONET, SMTP and FTP. This also allows 

applications 172 to be abstracted from the underlying 
native message layer 180. In one embodiment, three 
levels of messaging are provided having different 
characteristics: fast/reliable messaging; certified 

15 messaging; and guaranteed/ transactional messaging. The 
fast/reliable messaging can provide a reasonable efforts 
attempt to deliver the messages. The certified messaging 
can provide certifications of message delivery to the 
client application. Third, guaranteed/ transactional 

20 messaging can be provided between queues on transactional 
databases to ensure delivery of messages, including 
messaging between different transactional databases 
(e.g., between ORACLE and SYBASE databases or between 
RDBMS and ODBMS databases) . 

25 FIGURE 8 is a block diagram showing transactional 

queuing and messaging between applications according to 
the present invention. As shown, a first application 190 
has a transactional context that can include a storage 
192 holding relational database information 194 and 

30 transactional queues 196. A queue manager 198 provides 

an interface to queues 198 for application 190 as well as 
a transactional message manager (TMM) 200. Within a 
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messaging transactional context/ a message bus manager 
202 provides an interface between transactional message 
manager 200 and native messaging layer 204. 

Similarly a second application 206 has a 
5 transactional context that can include a storage 208 

holding object database information 210 and transactional 
queues 212. A queue manager 214 provides an interface to 
queues 212 for application 206 as well as a transactional 
message manager (TMM) 216. Within the messaging 

10 transactional context , a message bus manager 218 provides 
an interface between transactional message manager 216 
and native messaging layer 204. 

This framework allows an abstract queuing and global 
messaging layer between applications 190 and 206 to be 

15 supported on an underlying native messaging layer 204. 

Within this messaging framework, point-to-point messaging 
with global addressing, publish and subscribe messaging 
and efficient encrypted, user-authenticated messaging can 
be supported. Further, an out-of-the-box solution 

20 consisting of message bus adaptors to ACTIVEWEB or TIBCO, 
and queue adaptors on top of an ODBC compliant database 
can be provided. These adaptors can be bundled along 
with the messaging solution (ACTIVEWEB or TIBCO) to 
create the out-of-the-box messaging solution. 

25 

Model Agents 

The core environment is an inter-domain architecture 
that allows, for example, inter-enterprise optimization. 
Aspects of the environment that address a need for an 
30 inter-domain solution include: a security framework (both 
user interface to engine and messaging) , messaging that 
is global in scope (including a global naming scheme, and 
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transactional messaging to allow multiple transactional 
domains to be kept transactionally consistent) . Further, 
inter-domain analysis and optimization are enabled by 
allowing domains to exchange model agents that comprise 
5 partial replicas of the remote domains. 

FIGURE 9A is a block diagram of a naive approach to 
inter-domain analysis. As shown, an environment 220 can 
include a plurality of domains 222, 224 and 226 (domains 
A, B and C) . The naive approach is characterized by a 

10 distributed analysis, represented by arrow 228, in which 
distributed algorithms are run directly across the 
multiple domains 222, 224 and 226. This approach has 
some severe drawbacks. For example, reliability falls of 
dramatically as the number of domains increases- Also, 

15 in this approach, permissibility (i.e., one domain 
allowing access by another domain to its model) and 
security need to be intrinsically bound up with the 
distributed analysis. This places a heavy burden on the 
analysis algorithm and would function too slowly but for 

20 the simplest of analysis algorithms. Another 

alternative, not shown, is to have every domain 222, 224 
and 226 independently model all of the other domains 222, 
224 and 226. This approach, however, suffers from the 
difficulty of accurately knowing the model and data for 

25 other domains 222, 224 and 226. This approach also 

suffers from a scaleability problem with going to large 
numbers of domains 222, 224 and 226. 

FIGURE 9B is a block diagram of the use of model 
agents as partial replicas of remote domains according to 

30 the present invention. The model agents provide an 

alternative mechanism that makes feasible inter-domain 
analysis and optimization. As shown, an environment 230 
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can include a plurality of domains 232, 234 and 236 
{domains A, B and C) • These domains 232, 234 and 236 
each have models that are used for local planning 
analysis and optimization. According to the present 
5 invention, domains 232, 234 and 236 transfer model agents 
to each other that are partial replicas of the respective 
domains' model. The transfer of these model agents is 
preferably via a push scheme to subscribing domains, but 
may involve pull schemes or other transfer schemes. For 

10 example, domain 232 (domain A) provides a model agent 238 
to domain 236 (domain C) that is a partial replica of the 
model for domain 232, Model agent 238 comprises that 
portion of the model for domain 232 that is needed by 
domain 236 and to which domain 232 desires to grant 

15 external access. Similarly, domain 234 (domain B) can 
provide a model agent 240 to domain 236 (domain C) that 
is a partial replica of the model for domain 234. Again, 
model agent 240 comprises that portion of the model for 
domain 234 that is needed by domain 236 and to which 

20 domain 234 desires to grant external access. As a 

result, instead of running a distributed analysis over 
multiple domains, model agents 238 and 240 allow a local 
analysis, as represented by arrow 242, to be run on 
domain 236 using a combination of the local model (for 

25 domain C) and portions of the remote models (for domains 
A and B) as represented by model agents 238 and 240. 

As should be understood, the use of model agents as 
partial replicas of remote domains allows each interested 
domain to accomplish inter-domain analysis and 

30 optimization via local processes. Additionally, 

mechanisms can be provided to continually replenish the 
model agents from remote domains by pushing the model 
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agents to all subscribing domains, or otherwise providing 
updates to other domains . The model agents are thus 
partial replicas of models that can be passed around 
networks as discrete packages. It should be understood 
5 that the ^'partial" aspect can be important since 

typically a domain would wish to send another domain only 
a portion of its complete model rather than the whole 
thing . 

In one embodiment, there are three levels of model 

10 agents, each with increasing degrees of sophistication. 
The first level is data model agents. These are the 
simplest of the three and are used to pass around pure 
data. The second level of model agents are object model 
agents. These model agents allow entire graphs of 

15 objects to be passed around. Allowing graphs of objects 
to be passed around enables sophisticated forms of 
collaboration that would be difficult to achieve only 
with data model agents. For example, using object model 
agents, one domain can send another a partial picture of 

20 its supply chain model. The third level of model agents 
are behavior model agents. These model agents are more 
sophisticated and allow entirely new behaviors to be 
passed from one domain to another. For example, one 
domain could send another domain a new pricing policy or 

25 inventory policy as a behavior model agent. 

The model agents of the present invention solve both 
the infeasibility and scaleability problems of other 
inter-domain approaches. The model agents allow a needed 
portion of a remote domain to reside locally and be used 

30 for analysis and optimization. The model agents are 

generally extracted by each domain and provided to other 
subscribing domains. A subscribing domain can obtain 
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remote model agents preferably by having the model agents 
pushed to the domain, although other forms of 
subscription are possible. The model agents broadly 
enable inter-domain and inter-enterprise analysis and 
5 optimization and can embody key features of 

permissibility (only allowed portions are sent), pushed 
subscription (each domain pushes changes if they occur) , 
and hybrid composition (both state and behavior are 
transferred) . 

10 

Inter-domain connectivity plane 

FIGURE lOA is a block diagram of many-to-many 
interaction between domains, and FIGURE lOB is a block 
diagram of simplified domain interaction enabled by the 

15 inter-domain connectivity plane according to the present 
invention. As shown in FIGURE lOA, an environment 250 
can include a first domain 252 and a second domain 254. 
Domain 252 can include a number of applications 256, 258 
and 260. Similarly, domain 254 can includes a number of 

20 applications 262 and 264. In the many-to-many scheme of 
environment 250, applications 256, 258 and 260 of domain 
252 must handle data conversions between applications 262 
and 264 of domain 254, and vice versa. Further, each 
application has concerns about security and 

25 permissibility, and multiple inter-domain communication 
channels must be maintained. 

FIGURE lOB is a block diagram of simplified domain 
interaction enabled by the inter-domain connectivity 
plane of the present invention. As shown, an environment 

30 270 can include a first domain 272 and a second domain 
274. Domain 272 can include a number of applications 
276, 278 and 280, and domain 274 can include applications 
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282 and 284. As has been described/ data and information 
from domains 272 and 274 can be abstracted and provided 
to engines 286 and 288. Engines 286 and 288 then 
interact on the inter-domain connectivity plane thus 
5 simplifying the interaction between domain 272 and 274. 
The inter-domain connectivity plane, upon which various 
domain engines 286 and 288 can interact, thereby allows 
multiple, diverse entities (e.g., enterprises, divisions, 
etc.) to link supply chain operations. 

10 FIGURE 11 is a block diagram of one embodiment of an 

inter-domain connectivity plane according to the present 
invention. As shown, an environment 290 includes a 
native plane 292. Native plane 292 can include native 
sources 294 associated with a first domain and native 

15 sources 296 associated with a second domain. Native 

sources 294 and 296 can comprise data sources, planning 
engines and other domain related data and applications. 
Data and information from native sources 294 and 296 are 
abstracted onto an inter-domain connectivity plane 298 

20 using various adapters within the universal adapter 

framework as has been described. For example, business 
object servers (BOS's) can be used to raise data to 
inter-domain connectivity plane 298. A domain engine 300 
can be associated with the first domain and receives data 

25 and information abstracted from native sources 294. In 
an analogous manner, a domain engine 302 can be 
associated with the second domain and receives data and 
information abstracted from native sources 296. Inter- 
domain connectivity plane 298 can further include one or 

30 more domain engines 304 not specifically associated with 
a domain but operating on inter-domain connectivity plane 
298 to provide or perform desired functions. Inter- 
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domain connectivity plane 298 enables global messaging/ 
as represented by line 306, directly between domain 
engines 300, 302 and 304, as viewed by domain engines 
300, 302 and 304. However, the messaging is actually 
5 transparently supported by native messaging 308 on native 

plane 292. Inter-domain connectivity plane 298 provides 
an abstracted layer to allow harmonization across 
distributed domains and provides significant advantages 
by harmonizing such aspects as object structure, 

10 messaging paradigm, naming and security. 

FIGURE 12 is a block diagram of a hub and spoke 
collaboration network formed by engines on the inter- 
domain connectivity plane. As shown, an inter-domain 
connectivity plane 310 can include a plurality of domain 

15 engines 312 and 314. In the hub and spoke arrangement, 
engines 312 and 314 are associated with one of two kinds 
of domains or entities in the network. As shown, there 
are hub engines 312 and spoke engines 314. Hub engines 
312 can communicate simultaneously with multiple other 

20 hub engines 312. Spoke engines 314, on the other hand, 
only communicate with parent hub engines 312. 
Additionally, in one implementation, spoke engines 314 do 
not perform analysis but can only feed information to and 
be fed information from their parent hub engine 312. In 

25 another implementation, spoke engines 314 can be mid tier 

or web interface tier engines. In this scheme, the mid 
tier engines can perform some lightweight analysis, and 
the web interface tier engines do not perform analysis. 
Thus, the arrangement would enable three forms of 

30 communication within inter-domain connectivity plane 310: 
h\ib-to-hub, hub-to-spoke and user interface-to-hub. 

The inter-domain connectivity plane enables inter- 
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domain visibility, signaling, collaboration, analysis and 
optimization. Inter--domain visibility is a basic 
function of the inter-domain connectivity plane and gives 
visibility into data of other domains. Data can be 
5 pushed as well as pulled and can be used for user 

interaction as well as automatic analysis purposes. 
Inter-domain signaling allows domains to signal other 
domains. For example, the inter-domain connectivity 
plane can enable an early warning system in which a 

10 domain can signal other domains when certain conditions 
arise. The inter-domain connectivity plane also 
facilitates engine-to-engine collaboration across domains 
(as opposed to simple person-to-person collaboration) . 
Further, the inter-domain connectivity plane can enable 

15 inter-domain analysis and optimization in part by 

enabling the transfer of the model agents described 
above . 

The inter-domain connectivity plane is built upon 
the core environment and, as such, possesses the 

20 attributes and components of the core environment. Of 
these components, global messaging (used to message 
between multiple domains) and transactional messaging 
(used to keep the domains transactionally consistent) is 
important. Business object servers used to raise objects 

25 from the native plane to the inter-domain connectivity 
plane are also important. The engines on the inter- 
domain connectivity plane provide the bulk of the 
function and support numerous functions, including the 
early warning system, multi-domain collaboration, inter- 

30 domain analysis and optimization, a permissibility 

framework, and global naming. The engines support the 
model agents which enable partial mirroring of remote 
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models and support publish and subscribe model agent 
distribution. Security is also a fundamental attribute 
of the inter-domain connectivity plane. At the lowest 
level/ the inter-domain connectivity plane inherits the 
5 security features of the core environment including: user 
interface to engine security (authentication and 
encryption) and messaging security (authentication and 
encryption) . At the design level, security is ensured by 
a combination of permissibility and push technology. 

10 Scaleability is an important aspect, and the inter- 

domain layer is scaleable in several dimensions. 
Guaranteed asynchronous messaging increases scaleability 
by minimizing network dependencies. This can be 
especially critical as the number of communicating 

15 domains increases. Scaleability is also achieved by 
avoiding the many-to-many problem at the application 
level (security, permissibility and data conversion) . 
Scaleability is provided by allowing a single domain to 
talk to multiple other domains with no controlling 

20 domain. A domain typically needs to communicate with 
multiple other domains. However, the inter-domain 
connectivity plane allows the domains to do so without 
the need for any sort of higher level controller. 
Additionally if communications between a pair of domains 

25 breaks down, communications can continue between other 
domains, leading to far greater scaleability. 

Global naming 

The inter-domain connectivity plane can implement a 
30 global naming scheme that allows entities to be uniquely 
defined on a global basis. For example, the global 
naming scheme can comprise a three part naming scheme 
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using the Internet domain name server (DNS) at the 
highest level, enterprise name services (such as CORBA or 
LDAP) at the next level, and transient name services at 
the process level. With respect to naming, both name 
wrapping and name mapping provide harmonization. The 
name wrapping allows non-global names to be raised into a 
global name space and ensures unique naming when data is 
brought up to the inter-domain connectivity plane. Name 
mapping, on the other hand, provides a map to ensure that 
different names for the same object refer to the same 
object. Name mapping can allow two global names to 
refer to the same entity by mapping the names to each 
other. 

Although the present invention has been described in 
detail, it should be understood that various changes, 
substitutions and alterations can be made hereto without 
departing from the spirit and scope of the invention as 
defined by the appended claims. 
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WHAT IS CLAIMED IS: 

1. A computer implemented system providing a 
global user interface, comprising: 

a plurality of application engines each having an 
engine interface, the plurality of application engines 
composed of a plurality of types of engines; 

a user interface process, the user interface process 
providing an interface based upon user interface 
components; and 

a visual information broker operating as a middle 
tier to the plurality of application engines and the user 
interface process; 

the visual information broker having dynamically 
loadable adapters, each adapter appropriate for accessing 
one of the plurality of types of engines; 

such that the visual information broker can 
interface between the engine interface of an application 
engine and the user interface process by dynamically 
loading an adapter appropriate for that type of engine. 

2. The system of Claim 1, wherein the user 
interface process comprises a local caching proxy server 
with which the visual information broker communicates, 

3. The system of Claim 1, wherein the user 
interface process includes a library of data-aware 
components • 

4. The system of Claim 3, wherein the user 
interface process includes ACTIVEX components. 
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5. The system of Claim 3, wherein the user 
interface process includes JAVABEANS components. 

6. The system of Claim 1, wherein the visual 
information broker is operable to load-balance 
application engines of the same type. 

7. The system of Claim 1^ wherein the types of 
engines include databases, in-memory engines , CORBA 
servers/ flat-files, messaging, and object databases. 

8. The system of Claim I, wherein the dynamically 
loadable adapters support data models including tables, 
trees, name-value pairs, multi-dimensional, and object 
graphs . 
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9. A computer implemented process for providing a 
global user interface, comprising: 

establishing a plurality of application engines each 
having an engine interface, the plurality of application 
engines composed of a plurality of types of engines; 

establishing a user interface process, the user 
interface process providing an interface based upon user 
interface components; and 

interfacing between the engine interface of an 
application engine and the user interface process by 
dynamically loading an adapter appropriate for that type 
of engine; 

each adapter one of a plurality of dynamically 
loadable adapters appropriate for accessing one of the 
plurality of types of engines. 

10. The process of Claim 9, wherein establishing a 
user interface comprises establishing a user interface 
that comprises a local caching proxy server. 

11. The process of Claim 9, wherein establishing a 
user interface comprises establishing a user interface 
that includes a library of data-aware components. 

12. The process of Claim 11, wherein the user 
interface includes ACTIVEX components. 

13. The process of Claim 11, wherein the user 
interface includes JAVABEANS components. 
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14. The process of Claim 9, further comprising 
interfacing between the engine interface of an 
application engine and the user interface process to 
load-balance application engines of the same type. 

15. The process of Claim 9, wherein the types of 
engines include databases, in-memory engines, CORBA 
servers, flat-files, messaging, and object databases, 

16. The process of Claim 9, wherein the adapters 
support data models including tables, trees, name-value 
pairs, multi-dimensional, and object graphs. 
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17. A computer implemented system providing a 
global messaging bus, comprising: 

native messaging supported by a native message 
protocol across a network messaging layer; 
5 a plurality of message bus manager processes/ each 

message bus manager process associated with a software 
application and comprising: 

a dynamically loadable message bus adapter 
appropriate for the native message protocol and 
10 communicating across the network messaging layer; and 

a message bus application program interface 
appropriate for and communicating with the associated 
software application; 

the plurality of message bus manager processes 
15 enabling global messaging between the software 

applications by adapting to the native message protocol 
of the network messaging layer. 



20 



18. The system of Claim 11, wherein the network 
messaging layer is from the group of ACTIVEWEB/ TIBCO/ 
MQSERIES, NEONET, SMTP and FTP. 
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19. The system of Claim 11, further comprising: 

a plurality of databases, each associated with one 
of the software applications and having a transaction 
queue ; 

a plurality of queue manager processes, each queue 
manager process associated with a software application 
and comprising: 

a dynamically loadable queue adapter 
appropriate for the database associated with the 
associated software application; and 

a queue application program interface 
appropriate for and communicating with the associated 
software application; and 

a plurality of transactional message managers, each 
transactional message manager associated with a software 
application and interfacing between the associated queue 
application program interface and the associated message 
bus application program interface; 

such that transactions from the transaction queues 
can be communicated between different types of databases. 

20. The system of Claim 19, wherein the databases 
are composed of relational database management systems 
and object oriented database management systems • 
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21. A computer implemented process providing a 
global messaging bus, comprising: 

establishing a network messaging layer that supports 
native messaging by a native message protocol; 

establishing a plurality of message bus manager 
processes, each message bus manager process associated 
with a software application; 

interfacing, at each message bus manager process, 
between the network messaging layer and each software 
application by dynamically loading message bus adapters 
appropriate for the native message protocol and using 
message bus application program interfaces appropriate 
for each software application; 

the plurality of message bus manager processes 
enabling global messaging between the software 
applications by adapting to the native message protocol 
of the network messaging layer. 

22. The process of of Claim 21, wherein the network 
messaging layer is from the group of ACTIVEWEB, TIBCO, 
MQSERIES, NENOET, SMTP and FTP. 
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23. The process of Claim 21, further comprising: 
• establishing a plurality of databases, each 

associated with one of the software applications and 
having a transaction queues- 
establishing a plurality of queue manager processes, 
each queue manager process associated with a software 
application; 

interfacing, at the queue manager processes, with 
the databases by dynamically loading queue adapters 
appropriate for the database and using a queue 
application program interface appropriate for the 
associated software application; and 

interfacing between the associated queue application 
program interface and the associated message bus 
application program interface using a plurality of 
transactional message managers each associated with a 
software application; 

such that transactions from the transaction queues 
can be communicated between different types of databases. 

24. The process of Claim 23, wherein the databases 
are composed of relational database management systems 
and object oriented database management systems. 
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